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Intellectual Property Rights 

IPRs essential or potentially essential to the present deliverable may have been dcchired to 3( iPP and/or its 
organizational partners. The information pertaining to these essential IPRs, if any. is publicly available lor 3GPP 
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Note: The content has to be reviewed according to the 3GPH IPR rules. 



Foreword 

This Technical Specification has been produced by die 3 GPP. 

The contents of the present document arc subject to continuing work within the TSG and may change following 
formal TSG approval. Should the TSG i noddy the contents of this TS. it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows; 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information: 

2 presented to TSG for approval; 

3 Indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z die third digit is incremented when editorial only changes have been incorporated in the specification. 
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1. Scope 

The scope of this description is the specification of the MAC protocol. 

The following lists the contents for the specification of the MAC protocol: 
I. list of procedures 

logical How diagrams for normal procedures 
logical description of message 
principles for error handling 

some exceptional procedures which are felt criteria 

It should, as far as possible, have the same format and outline as die final specification 

7. exact message format 

8. all scenarios 



Ntfte: The list has la be reviewed. 
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2. References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• l : or a specific reference, subsequent revisions do not apply. 

• For a non specific reference, ihe latest version applies. 

• A non -specific reference to an TS shall also be taken to refer lo laier versions published as an l;N with the same 
number. 



[1] 3GPP Homepage: www.3GPP.org 

[2] TS25.301, Radio Interface Protocol Architecture 

[3] TS25.302, Layer 1 ; General requirements 

[4] TS25.303, UE States and Procedures in Connected Mode 

[5] TS25.304, Description of procedures in idle Mode 

[6] TS25.322, Description of RLC protocol 

[7] TS25.331, Description of RRC protocol 

[8] TS25.391. Description of principles for error handling and message description 
[9] ETSI UMTS 25.XX: "Vocabulary for the UTRAN" 
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3. Definitions, abbreviations and symbols 

3.1 Definitions 

Sec | *> | for a definition of.lundameiual concepts and vocabulary. 

3.2 Abbreviations 



ARQ Automatic Repeal Request 

ASC Access Service (Mass 

BCCl I Broadcast Control Channel 

BCH Broadcast Channel 

C- Control - 

CC Call Control 

CCCII Common Control Channel 

CCTrCI I C(Hled Composite Transport Channel 

C1*CII Common Packet Channel (in.) 

CN Core Network 

CRC Cyclic Redundancy Check 

IX* Dedicated Control (SAP) 

IK" A I )ynamic Channel Allocation 

IXX'II Dedicated Control Channel 

DO I Dedicated Channel 

DL Downlink 

DRNC Drill Radio Network Controller 

DSCI! Downlink Shared Channel 

DTCTI ^Dedicated Traffic Channel 

I ; AC 1 1 1 ; or ward Link Acce ss C h an n e I 

FAUSCII Fast Uplink Signalling Channel 

1 : CS I Tame Check Sequence 

LDD Frequency Division Duplex 
GC Cieneral Control (SAP) 

IK) Handover 

ITU International Telecommunication Union 

kbps kilo- hits per second 

I I (.aycr I (physical layer) 

L2 l^yer 2 (data link layer) 

1-3 La yer ^ ( n et work I aver ) 

LAC Link Access Control 

LAI Location Area Identity 

MAC Medium Access Control 

MM Mobility Management 

Nt Notification (SAP) 

(X'CCH ODMA Common Control Channel 

ODCCI I ODMA Dedicated Control Channel 

ODCII ODMA Dedicated Channel 

ODMA Opportunity Driven Multiple Access 

ORACH ODMA Random Access Channel 

ODTCII ODMA Dedicated Traffic Channel 

W 'I f Paging Control Channel 

l*CH Paging Channel 

Protocol Data Unit 

I'HY Physical layer 

PhyCII Physical Channels 

RACII Random Access Channel 

Kl^ Radio Link Control 
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RNC 


Radio Network Coturoiler 


RNS 


Radio Network Subsystem 


RNTl 


Radio Network Temporary Identity 


RRC 


Radio Resource Control 


SAP 


Service Access Point 


seen 


Synchronization Control Channel 


sen 


S ynch ri >n i /.at ion Chan nel 


SDU 


Service Data Unit 


SRNC 


Serving Radio Network Controller 


SRNS 


Serving Radio Network Subsystem 


TDD 


Time Division Duplex 


TITI 


Transport Format Combination Indicator 


III 


Transport Format Indicator 


TMSI 


Temporary Mobile Subscriber Identity 


TIT 


Transmit Power Control 


II- 


User- 


UH 


User Fquipment 


uf k 


User Fquipment with ODMA relay operation enabled 


UK 


Uplink 


UMTS 


Universal Mobile Telecommunications System 


URA 


I H RAN Registration Area 


USCII 


Uplink Shared Channel 


utra 


UMTS Terrestrial Radio Access 


UTRAN 


UMTS Terrestrial Radio Access Network 



3.3 Symbols 
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4. General 

4.1 Objective 

4.2 Overview on MAC architecture 

The following provides an overview of a common MAC architecture that encompasses both IJMTS-FDD and UMTS- 
TDD. There are differences of detail between the two systems but their architectures arc sufficiently similar for a 
common overview to be adopted. Followed by section 4.2.1 MAC entities, where Uie different MAC entities are 
summarised, the sections 4.2.2-4 contain a more detailed description of die MAC architecture. 

Note: The contents have to be reviewed, changes depend on further contributions 



4.2.1 MAC Entities 

The diagrams that describe the MAC architecture are constructed from MAC entities. The en I i ties are assigned the 
following names. The functions completed by die entities are different in the 111: from those completed in the IJTRAN: 

• MAC-b. which identifies the MAC entity diat handles the broadcast channel (BCU). There is one MAC-b 
entity in each UF and one MAC-b in the IJTRAN for each cell. 

Note: The separation in two different BCCII is ffs. the control SAP may be split accordingly 

• MAC-p, which identifies die MAC entity dial handles the paging channel (PCI I). There is one MAC-p entity 
in each UF and one MAC-p in the UT RAN for each cell. 

• MAC-c. which identifies the MAC entity dial handles the forward access channel (FACH), die random 
access channel (RACII) and the Common Packet Channel (Ul. CPCII) for FDD. There is one MAC-c entity 
in each IFF and one in die IJTRAN for each cell. 

• MAC-d, denotes the MAC entity that is responsible for handling of dedicated logical channels and dedicated 
transport channels (DCH) allocated to a tJF. There is one MAC -d entity in the III*, and one MAC-d entitv in 
die IPfRAN for each III: Note: When a VE is allocated resources for exclusive use bx the hearers that it 
supports the MAC-d entities dynamically share the resources between the hearers and are responsible for 
selecting the TFU TFCI that is to be used in each transmission time interval. 

• MAC-sh. denotes die MAC entity Uiat handles downlink shared channels (DSCIF) for both FDD and TDD 
and uplink shared channels (USCIf) for TDD . There is one MAC-sh entity in each UF dial is using a DSCH 
and a USCH for TDD operation and one MAC-sh entity in the IJTRAN for each cell dial contains a DSCH 
and a USCH tor TDD operation. 

• MAC-sy. identities die MAC entity used in TDD operation to handle the information received on the 
synchronisation channel SCI I 

According to the RRC functions the RRC is generally in control of the internal configuration of the MAC. 

4.2.2 MAC-b , MAC-p and MAC-sy 

The following diagram illustrates die connectivity of the MAC-b , MAC-p and MAC-sy entities in a UF and in each 
cell of the I FT RAN: 
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ligure 4.2.2.1 in: side and UTRAN side architecture (BCCH JVC! I and SCTII) 



MAf'-h. MA('-p and M AC-sy represents SCI I. BCI I and l*CI I control entities, which are cell-specific MAC entities in 
the IfTRAN. In the III; side there is one SCI I, BCII and I'd I control entity per Ul;. The SC II control entity handles 
synchronisation channels lor die TIM) mode. The details of this entity are left lor further study. The MAC Control 
SAP is used to transfer Control information to each MAC entity. 

4.2.3 Traffic Related Architecture - UE Side 

ligure 4.2.3. 1 illustrates the connectivity of MAC entities. The figure shows a MAC-d servicing the needs of several 
DTCH mapping them to a number of IXML A MAC-sh controls access to a common transport channel. It is noted that 
because the MAC-sh provides additional capacity then it communicates only with the MAC-d rather than the DTCII 
directly. The MAC-c. which interfaces with the l ; ACII and RACH common signalling channels, is connected with the 
MAC-d lor transfer of data and RNTI. The MAC Control SAP is used to transfer Control information to each MAC 
entity. In the Tl)l) implementation the MAC-sh transfers data from die DSCII to the MAC-d and from the MAC-d 
to die IJSCII under control of die I'ACII. In the H)l> implementation, the MAC-c may transfer data from the MAC-d 
to iheCPCH. 



MAC Control 

..L 



DTCII 



MAC-c 



MA<>.S& : 



MAC-d 



— i — i — r~r 
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f igure 4.2.3.1 tJH side MAC architecture 
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Figure 4.2.3.2 shows the UH side MAC-c entity. The following functionality is covered: 

• The (VI) MUX box represents the insertion and detection of the Held in the MAC" header, indicating whether a 
common or dedicated logical channel is used. 

• The c-RNTl field in the MAC header is used to distinguish between UHs. 

• In the uplink, the possibility of transport format selection exists. 

• Selection of Access Service (lasses ( ASC ) for RAC1I, details on definition of ASC and die relation to the RACM I 
retransmission algorithm are lis. 

• Multiplexing/scheduling /priority handling is used to transmit the received information on RACM I and CIVI I. 

• Channel selection is used to select an appropriately sized and available CKTH for transmission. 

• Demultiplexing of received information inside MAC-c to CTCH is used to support Short Message Service Cell 
Broadcast ( SMS CB ) 
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Figure 4.2.3.2. UE side MAC architecture / MAC-c details 



Figure 4.2.3.3 shows the UH side MAC-d entity. The following functionality is covered: 

• Dynamic transport channel type switching is performed by this entity, based on decision taken by RRC. 

• The CYT MUX hox is used when multiplexing of several dedicated logical channels onto one transport channel is 
used. 

• The MAC-d entity using common channels is connected to a MAC-c entity that handles the scheduling of the 
common channels to which the UH is assigned. 

• The MAC-d entity using downlink shared channel is connected to a MAC-sh entity that handles the reception of 
data received on the shared channels to which die IJ1- is assigned. 

• In the uplink, transport format combination selection {out of die RRC assigned transport format combination set) 
performed to prioritise transport channels. 

• FAUSCII Handling indicates the function in the MAC-d supports the FAUSCII. details arc Its 

• Support of Ciphering / Deciphering for transparent RLC operation in MAC . see |2| for details on the concept. 
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Figure 4.2.3.3. UE side MAC architeclure/ MAC-d details 



ligurc 4.2.3.4 shows the UK side MAC-sh entity. The following functionality is covered: 



• RNTI is used on Uie DSCH Control Channel to identify the UK. Additionally, some timing / physical information 
is needed to tell the UH when to listen to DSCH. 

• Multiplexing is used lo transmit die received information on DSCH and DSCH Control Channel to the Mac-d. for 
TDD the multiplexing is used lo transfer data from MAC-d to USCII and receives control information for shared 
operation from MAC-c. 

The RLC has to provide RI.C-PDU\s to the MAC which fits into the available transport Nocks on die transport 
ch an nel s respect i vel y . 



3GPP 



13 



TS 25.321 V3.0.0 (1999-06) 



MAC - Control 



MAC d 



MAC -c 



Multiplexing 



read RNTI 
/physical 
info 



OSCH Control 0»*nn*4 



I 

USCM 



— r 

DSCM 



— Dal* Rom DL Oownlnfc 

ww AW *r.-.- A e»l*tn*l Control inform a ben TF Transport Formal 

TFC Transport Format Ceynt>*»anon 

NOTE ( 1. Trim DSCM Conttoi Own*/ ntmy t»« 'tp'osrttect by RNTI Ratio Network Tampoiary kfonBfy 

thm fACM tfmtmit mr* tar htrth+' **Joy ye )j Mr Equipment 

NOTE(2; Tha mu'Uptoiang fyncton hms to t>» r«M«M#tf *so UL Uptnk 
frt* corw*fDon fa '•*o* BrVT / physic*/ **to too* 



Figure 4.2.3.4. IJH side MAC architecture / MAC-sh details 



4.2.4. Traffic Related Architecture - UTRAN Side 

Figure 4 2.4, 1 illustrates the connectivity between the M AC entities from die UTRAN side. It is similar to the IFF est 

with the exception that there wilt he one M AC-d for each I Jl£"and^acirt JliTfvf AC^ftT hat is associated iv Ttha 1 

particular cell may be associated with that cells MAC-sh. MAC-c receives die CPCI I transport blocks MAC-c and 
Mac-sh are located in die controlling RNC while MAC-d is located in the serving RNC.Thc MAC Control SAP is 
used to transfer Control information to each MAC entity belongs lo one UH. 
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Figure 4.2.4. 1: IH'RAN side MAC architecture 
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Figure 4.2.4.2 shows the IJTRAN side M AC-c entity. The following functionality is covered: 

o The Scheduling - Priority Handling box manages FACH resources between the UK's and between data flows 

according to their priority. DL flow control is also provided to MAC-d. 
o The (VI) box represents the insertion and detection of the field in the MAC header, indicating whether a common 

or dedicated logical channel is used. 
° I -"or dedicated type logical channels, the c-UNTI field in the MAC header is used to distinguish between IJTs. 
o In the downlink, transport formal selection might be done if FACH is variable rate. 

o The multiplexing of (TCI I information and the CB-Scheduling function inside MAC-c supports the Short 
Message Service Cell Broadcast ( SMS CB ). 
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Figure 4.2.4.2 UTRAN side MAC architecture / MAC-c details 



Figure 4.2.4.3 shows the Ifl'RAN side MAC-d entity. The following functionality is covered: 

° Dynamic transport channel type switching is performed by this cnlity. based on decision taken by RRC. 

o The C/T MlfX box is used when multiplexing of several dedicated logical channels onto one transport channel is 

used. C/T Mux is also responsible for priority setting on data received from DCCII / 1)1 "CI I. 
o Fach MAC-d entity using common channels is connected to a MAC-c entity that handles the scheduling of the 

common channels to which die III- is assigned and DL (FACIf) priority identification to MAC-c (priority 

identification of each l>l>W for DTCII NUT data is FT'S). 
o Kach MAC-d entity using downlink shared channel is connected to a MAC-sh entity that handles the shared 

channels to which the Ul* is assigned and indicates the level of priority of each PDU to MAC-sh and to MAC-c. 
° In the downlink, scheduling and priority handling of transport channels is performed within the allowed transport 

formal combinations of the TFCS assigned by the RRC. This function supports the TFCI insertion in Ni*dc B . 
o FA I ISO I Handling indicates the function in the MAC-d supports the FAUSCIi. details arc Its. 
° Support ol Ciphering / Deciphering for transparent RLC operation in MAC . see |2| for details on the concept, 
o A How control function exists toward MAC-c and MAC-sh to limit buffering between MAC-d and MAC-c or 

MAC-sh entities. This function is intended to limit layer 2 signalling latency and reduce discarded and 
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retransmitted data as a result ofFACII or I XSCI I congestion. It also allows to handle quality of service if MAC-d 
requires it. 
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Figure 4.2.4.3 UTRAN side MAC architecture / MAC-d details 



Figure 4.2.4.4 shows the UTRAN side MAC-sh entity. The following functionality is covered: 

• A specific I J?: JD is needed when using the DSC 1 1 Control Channel to identify the UH on the DSCII. This specific 
ITH ID may he optimised lor DSCII and will be allocated when a RAB is mapped onto a DSCII. Additionally, some 
liming information is needed to tell the I IF when to listen to DSCII. 

• The scheduling /priority handling box in MAC-sh shares the DSCT I resources between the I FFs and between data 
Hows according to their priority. For TDD operation die demultiplex function is used to support the USCH and the 
connection to the MAC-c. 

• The scheduling/priority handling box also prioritizes between UL & DL capacity allocation indications when the 
FACI f is used lor both DSCII and VSCU control channels (FACI! is used for TDD - FDD is ITS). 

• [^ ( ^ C :illoca,ion is uscd to indicate the code used on the DSCII and the appropriate Transport format on die 

• Flow control is provided to MAC-d. 

( Note: Capacity allocation s>iichroni/.alion related to the USCIl/ DSCII transmission is lis ) 

The RLC has to provide RIXMWs to the MAC which Ills into the available transport bUvks on the transport 
channels respectively. 
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Figure 4.2.4.4 UTRAN side MAC architecture / MAC-sh details 



4.3 Channel structure 



The MAC operates on (he channels defined below; the transport channels are described between MAC and I. aver I. 
the logical channels arc described between MAC and RLC. The following sections provide an overview, die 
normative description can be found in |2| and |3| respectively. 



4.3.1 Transport channels 

Common transport channel types are: 

o Random Access Channel(s) (RACH) 

o Forward Access ChanncKs) (FACI 0 

o Downlink Shared Channel(s) (IXSCH) 

o DSCI I Control Channel 

o Common Packet Channel(s) (CPCH) for IfL MM.) operation only 

o Uplink Shared Channel(s) ( USCH). lor TIM) operation only 

o ODMA Random Access ChanncKs) (ORACH) 

o Broadcast Channel ( BCH) 

o Synchronisation Channel (SCH). for TDD operation only 

o Imaging Channel <IVH) 

Dedicated transport channel types are: 

o Dedicated Channel (DCH) 

o hast Uplink Signalling Channel (I AUSCII) 

o ODMA Dedicated Channel (OIXTI) 
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4.3.2 Logical Channels 

The MAC layer provides data transfer services on logical channels. A set of logical channel types is defined for 
different kinds ol data transfer services as offered by MAC Hach logical channel type is defined by what type of 
information is transferred. 

4.3.2.1 Logical channel structure 

The configuration of logical channel types is depicted in Figure 4.3.2.1: 



Control Channel 
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Figure 4.3.2.1 : Logical channel structure 

4.3.2.2 Control Channels 

Following control channels are used for transfer of control plane information only: 

• Synchronisation Control Channel (SCCIE) 

• Broadcast Control Channel (BC(TF) 

• Paging Control Channel (PCCII) 

• Common Control Channel (CCCI f) 

• Dedicated Control Channel (DCCTI) 

• ODMA Common Control Channel (OCCCH) 

• ODMA Dedicated Control Channel (ODCCID 

4.3.2.3 Traffic Channels 

Following traffic channels are used for the transfer of user plane information only: 

• Dedicated Traffic Channel (DTCH) 

• ODMA Dedicated Traffic Channel (ODTCII) 

• Common Traffic Channel (CTCI 1) 
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4.3.3 Mapping between logical channels and transport channels 

The following connections between logical channels and transport channels exist: 

o SCO I is connected to SCI I 

o BCCH is connected to BCH 

o PCCM is connected to PCI I 

o CCCI I is connected to RACI I and FACII 

o IX'CII and i) TCI I can be connected to either RACH and FACII, to CPCH and FACII, to RACI I and DSCII. to 

IX'H and DSCII. or to a DCIL the IXXII can be connected to FAUSCII. 
o OIXVII. OCCCII and TCI I can he connected to ORACH. ODCCII and ODTCII can he connected toOIXIl 
o CTCII may be mapped to FACII and DSCII or BCH, the mapping is ffs 
o I XVI I and D IVII can be mapped to the USCIl ( TDD only ). 

5. Services provided to upper layers 

5.1 Description of Services provided to upper layers 

Data transfer 

© Reallocation of radio resources and MAC parameters 
o Reporting of measurements 

The following potential service is regarded as a further study item: 
© Allocation/de-al local ion of radio resources 

6. Functions 

6.1 Description of the MAC functions 

The functions of MAC include: 

o Mapping between logical channels and transport channels. 

o Selection of appropriate Transport Formal for each Transport Channel depending on instantaneous source rate 

© Priority handling between data Hows of one I Jit 

o Priority handling between I JHs by means of dynamic scheduling 

o Priority handling between data Hows of several users on the the DSCH and FACII 

o Scheduling of broadcast, paging and notification messages 

© Identification of UFs on common transport channels 

° Multiplexing/demultiplexing of higher layer PDUs into/from transport blocks delivered to/from the physical layer 

on common transport channels 
° Multiplexing/demultiplexing of higher layer PDUs into/from transport block sets delivered to/from the physical 

layer on dedicated transport channels 
o Traffic volume monitoring 
o Monitoring the links of die assigned resources 
o Routing of higher layer signalling 

o Maintenance of a MAC signalling connection between peer MAC entities 
o Dynamic Transport Channel type switching 
° Ciphering for transparent RFC 

The following potential functions is regarded as further study items: 
° Processing of messages received at common control channels 
° Successive Transmission on RACI I 
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6.2 Relation between MAC Functions / Transport Channels and UE 
6.2.1 Relation between MAC Functions and Transport Channels 
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Tahtf / t/TR.\\' MAC functions corresponding to the transport channel (noteU 



(Notel) On FACH channel, the transport format set is limited. 

(Note2) Whether DSCH has the transport format set is under discussion 

(Note * ) The functions nol included in the table are listed below. 

• Mapping between logical channels and transport channels. 

• Traffic volume monitoring 

• Constrained execution of open loop power control algorithms 

lurther. the following additional functions are not included yet in the table : 

• Routing of higher layer signalling 

• Maintenance of a MAC signalling connection between peer MAC entities 

• Monitoring the links of the assigned resources 

• Processing of messages received at common control channels 



Note ( this table lias lo be reviewed ) 
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6.2.2 Relation of UE MAC functions corresponding to the Transport Channel 
MAC Functions and Transport Channels 
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.Table 2 CE MAC fitrn lions corresponding to the transport channel 



(Sole I i The RACll channel has the limited transport format set. 

Noic: This table has to be reviewed 



7. Services expected from physical layer 

see M S25.302 
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8. Elements for layer-to- layer communication 

8.1 Primitives between layers 1 and 2 

see TS25.J02 

8.2 Primitives between MAC and RLC 
8.2.1 Primitives 

The primitives between MAC layer and RI.C layer arc shown in Table X.2.1.1 



(Generic Name 


Type 


Parameters 


Request 


Indication 


Response 


Confirm 


MAC- DATA 


X 


X 






Ml J 


MAC-liKKOK 




X 






1 ITS | 


MAC -STATUS 




X 


X 




| ITS | 



Table 8.2.1 Primitives between MAC layer and RLC layer 

MAC- 1) ATA Request/Indication 

• MAC-DAT A Request primitive is used lo request thai an upper layer Pl)l I he seni using th e procedures lor the 
information transfer service. ~~~ 

• MAC-DATA Indication primitive indicates the arrival of an upper layer PDU received by means of the 
information transfer service. 

MAC-KRROR Indication 

• MAC-HRROR Indication primitive indicates lo RLC dial an error condition has occurred. 
MAC-STAITJS Indication/Response 

• MAC-S TA TUS Indication primitive indicates to RLC about changes in the rules under which it may transfer data 
to MAC. Parameters of die primitive can indicate a transmission timer value, whether the RLC can transfer data 
and whether that data is restricted lo supervisory frames only. 

• MAC-STATUS Response enables RLC to acknowledge a MAC-STATUS Indication. It is possible that RLC 
would use this primitive to indicate that it has nothing lo send or that it is in a suspended stale. 

8.2.2 Parameters 

a) Message Unit (MU) 

It contains die RLC layer message ( RLC-PDU) to be transmitted or received by die MAC sub-layer. 

I Note i from Tdoc WC2 009/99): This description are based on L2HC specification draped TTC/ARIB Joint 
meeting. Because SAP between LAC and MAC is defined in our structure of MAC, the name of Signal is changed 
to Primitive. And format of e xplanation of primitives are changed to avoid verbose description. Request and 
Indication are combined to explain. Primitives for Activation/Deactivation or Hstablish/Release or 
Connect/Disconnect for MAC connection are FFS. / 

[Note ( from Tdoc WG2 009/99;: The parameters for RLCM AC-ERROR and RLCMAC-STATUS are 
FFS. ] 
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8.3 Primitives between MAC and RRC 
8.3.1 Primitives 

The primitives between MAC and RRC are shown in Table 8.3.1 



Ceneric Name 


Type 


B'aranroeters 


Request 


Indication 


Response 


Confirm 


cmac-confh; 


X 








CHI 


CM AC- CONNECT 


X 






X 


lis 


CM AC- 
MEASUREMENT 
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X 






TRIG Til. 
RKSIJLT, PHR 


CMAC-STATUS 




X 






Status into. 


CM AC-ERROR 




X 






Reason lor error 



Table 8.3.1 Primitives between MAC sub-layer and RRC 



CM AC-CON FIG Request 

o CMAC-C()Nl : l(i Request is used to request lor the switching the connection between logical channels and 
transport channels 

CMAC-CONNFCT Request/Confirm 

o CMAC-CONNFCT Request is used initiate a RRC connection 

© CMAC-CONNFCT Confirm is used to confirm the establishment of a RRC connection. 
CMAC-MIiASURI'lMMNTRequesulndication 

o CM AC-MFASl tRHMIiNT Request is used to request to measure something radio quality at both BS and MS 

sides, (for example : Transport Block Hrror) 
o CMAC-MFASl JRJiMIiNT. Indication is used to notify measuring result. 



CMAC-STATUS Indication 

o CMAC-STATl IS Indication primitive notifies the management entity of status information. 
CMAC-HRROR Indication 

o CMAC-I-RROR Indication primitive notifies the management entity of an error delected in the operation of the 
MAC sub layer protocol such as excessive number of transmission attempts for Ack-mode. and timer time out. 



8.3.2 Parameters 



a) Channel Information (CID) 

Channel information for active transport channel. For example, common channel or dedicated channel 
notification in user packet transmission. 

b) Til 

Threshold information for measurement. For example, traffic monitor or transmission quality. 
When an specific value is assigned, it means measuring should be reported w ith law data. 

c) PI:R 
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Period information for measurement. When an specific* value is assigned, il means measuring should he reported 
only when measuring result exceed the given threshold. 

d) TRIG 

Trigger information winch request to start measuring. 

e) KHSUI.T 
Measurement result. 

0 Status info 

It is management entity of status information. 

g ) Reason for error 

It contains the management entity of an error detected in the operation of die MAC sub layer protocol (e.g. 
excessive number of transmission attempts for Ack-mode). 

|Note( from Tdoc WG2 009/99): If used with a threshold information, the MHASURH primitive is same as an alarm 
indication or request for channel switching. When the condition that channel switching is needed is detected at in- 
side, appropriate RRC message will be sent to Network side. 



9- Elements for peer-to-peer communication 
9.1 Protocol data units 

971 vl-MAC Data PDU 

MAC PIMJ consists of an optional MAC header and a MAC Service Data Unit (MAC SIM I), see figure M.I.I. BoLii the 
MAC header and the MAC SI Ml are of variable size. 

The content and the si/.e of the MAC header depends on the type of the logical channel, and in some cases none of the 
parameters in the MAC header are needed. 

The size of the MAC-SIM J depends on the size of the RIXT-PDIX which is defined during die setup procedure. 

MAC header MAC SDU 



< 









► 


C/D 


UE-ld 


C/T 


MAC SDU 



Figure 9.1.1.1 MAC data PDU 



9.1.2 MAC Control PDU 
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MAC Control 1*1)11 consist elements for Lhe control of the operation. The details arc ffs. 



9.2 Formats and parameters 

9.2.1 MAC Data PDU: Parameters of the MAC header 

The following fields are defined for the MAC header: 
• (71 Hick) 

The (71) Held is a single-hit Hag that provides identification of the logical channel class on I- AC 1 1 and RACI I 
transport channels, i.e. whether it carries CCCII or dedicated logical channel information. 



(71) field 


Designation 


1 


(TCI I 


0 


1 )CCH or DTCII 



Table ( ).2. 1.1: Coding of the C/D lucid 

• C/T field 

The C/T field provides identification of the logical channel instance when multiple logical channels are carried on 
the same transport channel. The C/T field is used also to provide identification of the logical channel type on 
dedicated transport channels and on I 'ACII and RACI I when used for user data transmission. The si/.c of the C/T 
field may he variable. 



C/T field 


Designation 


(e.g. 
4 hits ) 




(KMX) 


logical channel 1 


(MM)1 


logical channel 2 






1 1 1 1 


logical channel 16 



Table <> 2. 1 .2: Structure of the C/T field 

• IJIMd 

The ( Hi-Id field provides an identifier of the UH . The following t>pes of IJlMd are currently defined: 

s-RNTI . this III*: Id is related to die serving RNC 
c-RNTI. this U1-; Id is related to the controlling RNC. 

In addition lor UK's having a RRC connection the S-RNC identifier exist. 
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s-RNTI together with S-RNC identifier is used tor URA update RRC connection reestanlishmenl and I IT RAN 
originaied paying messages and iherc assiKialed responses. 

e-RNTl is used as a UK identifier in all other DCCl I/I) TCI I common channel messages on the air interlace. 
Note: Whether or not other UE-ld types are needed isffs. 

9.2.1.1 MAC header for DTCH and DCCH 

a) DTCH or DCCl I mapped lo DO I, no multiplexing of dedicated channels on MAC: 
No MAC header is required. 

h) DTCH or IX'CII mapped to DO I. with multiplexing of dedicated channels on MAC: 
C/T field is included in MAC header. 

c) DTCH or I XVI I mapped to RACH/KACII: 

(71) field and UK-Id are included in the MAC header. C/T Held is included it multiplexing on MAC is applied. 

d> DTCH or DCCl I mapped to RACI I/KACII. where DTCH or DCCH are the only channels (lis). 
UK-Id field is included in MAC header. C/T field is included if multiplexing on MAC is applied. 

e) DTCH or IX VI I mapped to DSC! I: 

The MAC-PI )U format lor DSCI! is left lor further study. 



Case a): 



MAC SDU 



Case b): 
Case c): 

Case d): 



C/D 



C/T 



UE-ld | C/T j 



UE-ld [ c/T 



MAC SDU 



MAC SDU 



MAC SDU 



Figure 9.2.2.1 : MAC Data PDU formats for DTCH and DCCH 



9.2. 1 .2 MAC header for CCCH 

Note: The concept for using UE Id on CCCH has to he reviewed 

a) CCCI I mapped to RAO I/I- AC 1 1: 

C/D has to he included and UK-id field may be included in MAC header. Details of usage the I !K-id field is lis. 
n) CCCI I mapped lo RACI l/KACI I. where CCCI I is the only channel (lis): 

I IK- id field may he included in the MAC header. 



Note: The usage of the MAC header for BCCH and PCCH isffs. 

The address used for initial addressing is ffs. a possible solution may be to use a Rand<wt or CN related Identifier. 
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Case a): 



C/D UE-ld 



MAC SDU 



Case b): 



UE-ld 



MAC SDU 



Figure 9.2.1.2.1 : MAC Data PDU formats for CCCH 



9.2.1.3 MAC Header for CTCH 

The MAC header for CTCH mapped to FACH is as shown in figure 9.2.1.3.1 



c/d err 



MAC SDU 



Figure 9.2.1 .3.1 : MAC Data PDU format for CTCH 



(71) field indicates whether data is mapped to the common or dedicated logical channel. 

(Yf Held indicates whether it belongs to CCCII or CTCH. In case of CTCIL it identifies whether the message is SMS 
CB message or Schedule message 



9.2.2 Control PDUs 

MAC Control PDU elements have to be described, the details are ffs. 

9.3 Protocol states 

(Description of stales, provision of state transition diagram(s)) 

9.4 State variables 

9.5 Timers 

9.6 Protocol Parameters 

(e.g. max, min values of state variables to be initialised) 

9.7 Specific functions 

(description of specific protocol functions, if applicable) 
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10. Handling of unknown, unforeseen and erroneous 
protocol data 



1 1 . Elementary procedures 

Examples: data transfer, random access procedure, transport channel type switching (dedicated/common 
channel) 

11.1 Dynamic radio bearer control in UE 

o This procedure is applicable only in case of optimisation of established radio bearers 

0 The algorithm exist in the UE and is controlled by the network. The algorithm requests to RRC for a 
reconfiguring of radio resources, details are ffs. 

1 1 .2 Control of RACH transmissions 

/ Note: This procedure has to he reviewed for FDD and TDD operation I 

The MAC sublayer is in charge of controlling the liming of RACII transmissions on transmission time interval level 
(i.e. on M) ms-radio frame level; the timing on access slot level is controlled by LI). MAC controls die liming of each 
initial preamble ramping cycle as well as successive preamble ramping cycles in case that none or a negative 
acknowledgement is received. Note that retransmissions in case of erroneously received RACII message pari are under 
control of higher layers ( fcTRITCroTRRC foTCCCI lllala): : — 

The RACII transmissions are performed by the IJ1* as shown in Figure 2. MAC receives die following RACIf 
transmission control parameters from RRC with the CMAC-Config-RLQ primitive: 

° persistence value P (transmission probability), 

° maximum number of preamble ramping cycles M ttux . 

o others (ffs.. e.g. minimum and maximum number of time units between two preamble ramping cycles). 

Based on the persistence value P. the IHi decides whether to start the LI power ramping procedure in the present 
transmission time interval or not. If transmission is allowed, the LI preamble power ramping procedure is started. 
MAC 1 dien waits for siatus indication from LI. If transmission is not allowed, a backoff timer T m „ is started and 
another attempt is performed after expiry of die timer. 

When the preamble has been acknowledged on AICII. the RACH message part is transmitted according to LI 
specifications. When no acknowledgement is received, a backoff timer T B oz is started and another preamble ramping 
cycle is performed. In case that a negative acknowledgement has been received on AIC! I a backof f timer Tn ()1 is 
started. After expiry of die timer persistence check is performed again. 

The settings of the backoff timers T B <>i. T Bo: T UtH is ffs. The setting is an integer number (> 1 ) of transmission time 
intervals, either fixed or randomly drawn from an interval defined by RACH transmission control parameters received 
from RRC. which might be updated dynamically, together with update of persistence value. 

1 Note: The three timers are introduced at this singe mainly to keep the algorithm most general. Possibly T Htn and 
T Ht): can simply he set to their minimum value, which is currently assumed to he 10 ms. However, smaller backoff 
timing units such as access slot hue mils may also be considered. The introduction uf random backoff withT Hn < 
could especially be useful when the update time for the persistence value is low, i.e. larger than a radio frame. 1 
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The backoff algorithm encompasses currently both 

(a) a persistency check and 

(b) a backoff lime 
at both stages, 

• initial (i.e. very first) attempt after the request to send RACII data has been received by MAC and 

• subsequent attempt, which is needed in case ol' the following conditions: 

(i) after an unsuccessful preamble ramping cycle (No Aek) 

(ii) after a Nack from U. 

l or both slages ii is I I S if both (a) and (b) are needed or if one of (a) or (b) is sufficient. 
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Wait Tr o: 



Start ^ 



Gel RAOII tx control parameters 
from RRC: P. M Illa „ other Ms. 
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Increment preamble transmission 
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Start LI preamble power ramping 
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Transmit RACH message part 
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Wait Tbc.i 



Wait Tijo, 



Figure 11.2.1 : RACH transmission control procedure (UE side, informative) 
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Annex A (informative): 



Description of random access procedure 

/ Note: This annex has to be reviewed for FDD and TDD operation] 

A 1 Assumptions 

The following assumptions for RAO I transmission are made (for completeness assumptions are made also lor other 
layers than MAC): 

UEside: 

• PRAO I transmissions are triggered by data request from MAC to PI IY (PI lY-Data-RIiQ). This implies dial any 
desired backoff in PRAO 1 transmissions is controlled by MAC (or higher layer). 

• The physical layer uses the PI IY-Status-INI) primitive to indicate the following conditions lo MAC: 
•—Maximum preamble transmit power reachedrn(> acknowlcdgemenl-on AK-ri-received; 

• Negative acknowledgement received on AICH CNack") indicating that the preamble has been acquired, but 

transmission of the message shall be suspended. 

• Positive acknowledgement received on AICII ("Ack"). RACH message has been transmitted. 

• The following PRAO I parameters are configured by RRC through C-SAP by means of CPI FY-TrCI I-Config-RHQ 
primitive: 

• initial transmit power. 

• power ramping step size. 

• preamble-to-message transmit power offset. 

• PRACII maximum power 

• PRACII spreading code. 

• Access Service Class (ASC) parameters (lis.). 

• Configuration of AICII parameters by RRC (using CPHY-TrCH-Config primitive) 

• AICI I spreading code 

• timing information for search of acquisition indicator (if needed) 

• The following parameters are randomly selected by the physical layer (possibly within constraints defined by ASC 
parameters): 

• PRAO I initial access slot. 

• PRACII signature 
UTRAN side: 

• Continuous monitoring of the PRACII is handled by layer I procedures. There is onlv a single primitive needed 
between PHY and M AC. indication of data (PHY -Data- 1 ND). 
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A. 2 Example message sequence for random access procedure 



RACH transmissions arc split into two phases, preamble power ramping and message transmission. The message is 
transmitted when acquisition of die preamble has been acknowledged, where a fixed liming between that lust 
transmitted preamble, (lie acquisition indicator and the message needs to be maintained. Under certain conditions (see 
below) it will be necessary to perform multiple attempts of preamble power ramping before the message can be sent. 

The timing of RACH transmissions on transmission time interval level is controlled by the MAC sublayer (i.e. 
introduction of backoff delay based on transmission time interval units). 

An example message sequence for random access is shown in Figure l. RACE I transmission is performed as follows: 

The RACE I and AICI I are configured once via a CPIIY TrCII-Config-RHQ primitive. This primitive needs to be 
issued only for initial configuration or when a parameter shall be changed, not for every RACH transmission. 

flic CMAC-Conlig-RI-Q primitive is used to configure MAC parameters required for the random access procedure. 
The parameters could include random access control parameters such as. e.g. persistence value, maximum number of 
preamble ramping cycles, and minimum and maximum backoff time in terms of number of transmission time intervals 
(i.e. radio frames of ID ms) when transmission is allowed. 

(Nate: Above listed access control parameters are only examples for further study. Also it is ffs how the access 
control parameters are obtained by RRC from e.g. broadcast information ./ 

When there is data to be transmitted on the RACE I. i.e. reception of a MAC-l)ata-RJ:Q primitive, the RACH 
transmission control procedure is started. 

After some initial backoff, a primitive PHY-Data-RKQ is sent to l.l, which triggers the PRACH preamble- 
transmission procedure, i .e. the physical layer selects a PRACIE access slot without further backoff delay imposed on 
LI (possibly within ASC constraints). Note that die initial backoff time may in certain conditions be set to zero (e.g. 
when the uplink load is low). 

In the example it is assumed that the preamble power ramping procedure is completed with one of the following 
conditions: 

(i) maximum permitted transmission power was reached wiUiout receiving an acknowledgement, or 

(ii) a negative acknowledgement (Nack) has been received on AICI I. 

The first condition can be due to following reasons: 

1. ) missed preamble in Node B at max power due to detection probability < I T 

2. ) collision widi another user. 

3. ) an acknowledgement was sent but it was missed at the Uli. 

This condition should occur very rarely and may not necessarily require backoff for a repetition of the preamble 
ramping cycle (except case I .) is due to overload, which however should be prevented by the system in some suitable 
way). I lowevcr some backoff should be imposed to provide a belter interference distribution over time. 

The second condition, reception of "Nack" on AICI I shall be used to prevent the user from sending his message in 
case ol danger of a temporary congestion (it could be ignored by "special users"). In Uiis case, a new access attempt 
should be started by MAC after some further backoff delay. Note dial this "subsequent" backolf time might be 
calculated differently than the initial backolf time applied in the first preamble power ramping cycle. Also, the 
subsequent backoff time may be set differently for either of the above conditions (i) and (ii). 

This condition could occur a number of consecutive limes. The number of preamble ramping cycles is counted on 
MAC. When the maximum number of cycles is exceeded an error condition is signaled to RRC* (with CMAC-Stalus or 
CMAC-iirror primitive, lis.) and the MAC PDU is removed. 

Upon successful transmission of a preamble. MAC receives an acknowledgement via PHY-Stalus-INI) primitive thai 
the acquisition indicator was received and the message sent. 

At the in RAN-side MAC the further processing of received RACE! message depends on the MAC header. An 
acknowledgement that the message was received correctly is cither be given by RRC procedure or by a RLC 
retransmission procedure, depending on the type of the message. The parameters of PRACI I transmission arc chosen 
such that retransmission of the messages is a very rare event. Incorrectly received messages should not be due to 
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overload situations since this condition should have been signaled via the Nack on AICI I alter preamble acquisition. It 
is thus not needed to impose an additional outer backoff time for retransmission of the message. Message 
retransmission shall be handled entirely on RIX\ or RRC for CCC II messages, employing retransmission timers. 

It should be noted that lor transmission on common transport channels some parameters of the RIX* retransmission 
protocol may need to be updated to cope with delays introduced by the MAC RACH transmission control function. 

[Note: An additional negative acknowledgement {Sack) given by LI for erroneously received RACH message part is 
JfsJ 
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Figure A.1: Example random access transmission sequence 
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ANNEX B (informative): 
Control of CPCH 

B.1 Overview 

The Common Packet Channel (CIVII) is multi-access contention based transport channel in the uplink 

The MAC may multiplex control and user data from multiple logical channels in the same CPCH transmission. The 
MAC functions associated with the (TXT I are 

• Scheduling 

• Multiplexing/demultiplexing 

• In band identification oflJHs 

Procedures associated with the CPCH are 

• CPCH access procedure ( see Annex B in TS25.30I|2| ) 

B.2 Scheduling of control and user data transmission 

Scheduling of control and data transmission on CI*Cll is similar to dial of RACI I (cf. 14.2.4.2). 

Transmission scenarios for CPCH include: 

• Initial CI*CH transmission 

• CPCH Busy Retransmission 

• Collision Delected Retransmissio 

B.3 Multiplexing/demultiplexing of higher layer PDUs to/from CPCH 
transport blocks 

HI: MAC supports service multiplexing for CPCH transport channels similar to die RACH (cf. 14.2.4.3). 

B.4 Inband Identification of UEs 

Inhand identification of Ul-s for the CPCH is identical to that for the RACH (cf. 14.2.4.4) 
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B.5 Selection of CPCH Channel 

III- MAC monitors the availability of the CPCH channels in the CPCH Set allocated to the III-:. UK MAC selects an 
available channel considering RNC persistency parameter and the capacity of the CPCI I. If access to the selected 
CIVII is denied, channel reseiection and retransmission may occur. 



ANNEX C (informative): 

MAC peer to peer communication 

C.1 MAC messages for MAC peer to peer communication 

(Note: Based on Tdoc TSCiRAN WG2 2X5/ W for the use of MAC peer lo peer communication W( i2 lias agreed lo 
incorporate MAC messages lor peer lo peer communication into TS25.321. details are for further sludv.) 

C.2 Format of MAC messages for MAC peer to peer 
communication 



) { Note: Based on Tdoc TSGRAN WG2 2K5/ W for the use of MAC peer to peer communication WG2 has agreed to 
, incorporate MAC messages for peer to peer communication into TS25.321. details are for further study.) 
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